Lookup tables for text rendering

ABSTRACT

Systems and methods are provided for improved filtering and correcting of glyphs on a GPU. The computational intensity required for filtering and/or rendering can be reduced by pre-calculating some or all of the calculations needed for converting coverage data into corrected pixel values. Additional efficiencies may be realized in some embodiments by transferring data from a CPU to a GPU in an improved format. The improvements can be realized in a variety of graphics formats.

BACKGROUND

A glyph is an image used to visually represent a character orcharacters. For example, a font may be a set of glyphs where eachcharacter of the font represents a single glyph. However, a glyph mayalso include multiple characters of a font and vice versa. That is, onecharacter of a font may correspond to several glyphs or severalcharacters of a font to one glyph. In other words, a glyph is the shapeof a series of curves that delimit the area used to represent acharacter or characters. The computer-implemented process used togenerate glyph curves and the resulting characters is referred to astext rendering.

Rendering text can be one of the more expensive operations in terms ofcentral processing unit (CPU) usage. One process for rendering textincludes the four step process of rasterizing, merging, filtering, andcorrecting. The rasterizing step includes converting the glyph curves toa bitmap. The format of the bitmap is typically 1-bit-per-pixel (1 bpp)and it may be “overscaled” in one or more directions. For example, thebitmap may be overscaled in the vertical or horizontal direction.Overscaling refers to a process where each bit of data, or texel, usedto generate the bitmap is smaller than the pixel used to display theglyph.

The merging step includes merging nearby glyphs to prevent artifacts orundesirable characters. For example, anti-aliasing (including sub-pixelrendering) involves drawing some pixels semi-transparently. Because eachglyph may be drawn independently, it is possible for the same pixel tobe drawn semi-transparently multiple times in locations where the glyphsoverlap. This may result in the pixel appearing too dark. To avoid this,the merging step combines the bitmaps for all the glyphs into a singletexture. The filtering and blending steps are performed on the singletexture rather than separately for each glyph. Thus, the merging stepscombines the individual glyphs to achieve a continuous appearance andensure there are not overlapping or separated glyphs.

The filtering step takes the merged glyphs and calculates the “coverage”for each pixel. The term coverage refers to determining the necessaryintensity or value for each individual pixel used to display the mergedglyphs. For example, a pixel that falls completely within the area ofthe glyph curve would have a 100% coverage. Likewise, a pixel that iscompletely outside the area of the glyph curve would have 0% coverage.Thus, the coverage value may fall anywhere in between 0% to 100%depending on the particular filtering method used for rendering theglyph.

The correcting step may include sub-pixel rendering to improve thereadability of the characters. One example of correcting can involvemodifying the coverage for each pixel based on known factors thatimprove the readability of a glyph. These can include emphasizing orde-emphasizing certain colors and/or pixels within a glyph to avoidappearance artifacts when a glyph is displayed. Another example ofcorrecting can be blending of pixels to exploit the pixel structure of aLiquid Crystal Display (LCD). Specifically, sub-pixel rendering ispossible because one pixel on an LCD screen is composed of threesub-pixels: one red, one green, and one blue (RGB). To the human eyethese sub-pixels appear as one pixel. However, each of these pixels isunique and may be controlled individually. Thus, the resolution of theLCD screen may be improved by individually controlling the sub-pixels toincrease the readability of text displayed on the LCD.

One method to render the text is to perform the first three steps on theCPU. That is, the rasterizing, merging, filtering steps are performed onthe CPU and the blending step is preformed on the graphic processingunit (GPU). In terms of CPU usage, the merging and the filtering stepsare the most computational intensive.

SUMMARY

In various embodiments, systems and methods are provided for improvedfiltering and correcting of glyphs on a GPU. The computational intensityrequired for filtering and/or rendering can be reduced bypre-calculating some or all of the calculations needed for convertingcoverage data into corrected pixel values. Additional efficiencies maybe realized in some embodiments by transferring data from a CPU to a GPUin an improved format. The improvements can be realized in a variety ofgraphics formats.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid, in isolation, in determining the scope of the claimedsubject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is described in detail below with reference to theattached drawing figures, wherein:

FIG. 1 is a block diagram of an exemplary computing environment suitablefor use in implementing embodiments of the present invention.

FIG. 2 schematically shows an example of components for rendering textpixels.

FIG. 3 depicts a flow chart of a method according to an embodiment ofthe invention.

FIG. 4 depicts a flow chart of a method according to an embodiment ofthe invention.

FIG. 5 depicts a flow chart of a method according to an embodiment ofthe invention.

FIG. 6 schematically shows another example of components for renderingtext pixels.

FIG. 7 shows the alignment of 6×1 pixel coverage data stored in an8-bits-per-byte format.

DETAILED DESCRIPTION

After a bitmap of a glyph is determined, rendering text based on theglyph bitmap can require completion of several tasks. One can includetransferring coverage data for rendering from a central processing unit(CPU) to a graphics processing unit (GPU). Another task can be unpackingthe transferred data into a recognizable format. A third task can beconverting the coverage data into pixel information. Additionally,various corrections can be applied to the pixel to improve the finaldisplay of the text. Rendering text in an efficient manner can involvebalancing the memory requirements and processing requirements fordisplaying pixels based on coverage data.

Data Transfer and Unpacking

Transferring coverage data from the CPU to the GPU is one possiblebottleneck during text rendering. Conventionally, coverage data has beentransferred in a simple format, such as transferring one-bit-per-pixel(1 bpp) data by using a separate byte to hold each bit of data. Using abyte to hold each bit of 1 bpp data simplifies the unpacking of datatransferred to the GPU, as each bit is located in a separatelyaddressable location. However, this type of data transfer can beinefficient from a memory standpoint, as the majority of data space ineach byte is not used. This inefficiency can be exacerbated by anyoversampling used in representing the pixel data. For example, onecommon type of oversampling for text data (such as ClearType data) is touse a 6×1 coverage data format for each pixel. In a 6×1 format, 10 totalbits are needed to represent three channels of data for the pixel. Thechannels typically correspond to the red, green, and blue components ofa pixel. Thus, when transferring data in a 1 bpp format with a separatebyte for each bit, 10 bytes are needed to transfer the red, green, andblue components for the pixel. In this type of data transfer, the bitsnecessary to specify a pixel are easily assembled, as the 10 bits can beretrieved from their individual bytes that do not include any otherdata.

In various embodiments, an improved method is provided for transferringand/or unpacking coverage data. Instead of transferring the 1 bbp datawith each bit in a separate byte, data can be passed into the GPU usinga higher data density format, such as 8-bits-per-pixel. This increasesthe amount of data transferred in each byte, which can reduce theoverall memory usage on the GPU.

Transferring data in a higher data density format can require additionalprocessing to unpack the data. Due to the higher density format, theinformation for each pixel may not cleanly align with the boundaries ofindividual bytes. For example, 6×1 coverage data includes 10 bits ofinformation per pixel, while an 8 bpp data format includes only 8 bitsper byte. Additionally, for glyphs corresponding to ClearType text, eachpixel overlaps with an adjacent pixel by 4 bits due to overlap in pixelinformation for the ClearType filter. As a result, for an example of 1bpp ClearType text transferred using an 8 bpp packing scheme, each byteof transferred data can include information for more than one pixel, anddetermining the display value for a pixel can require data from morethan one byte. This situation is shown in FIG. 6, which shows an exampleof how 6×1 coverage data is stored in an 8 bpp format.

The method for unpacking the coverage data can depend on the type ofdisplay hardware that is available. For a hardware display using theDirectX 10 format (Dx10), bit shifting instructions are available. Thismeans that any pixel information that is needed can be obtained byaccessing the two bytes of data that contain the 10 bits correspondingto a pixel. Bit shifting instructions can then be used to select thebits within each byte that correspond to the pixel of current interest.The bits can then be assembled to form a 10-bit number corresponding tothe coverage data for the pixel. Similar manipulations can be used forother data formats, based on the relationship between the number of bitsin a pixel relative to the packing of the coverage information.

Additional operations may be needed for hardware that does not includebit shifting functionality. For example, DirectX 9 (Dx9) does notsupport bit shifting operations. Instead, information sampled by thepixel shader in Dx9 is returned as floating point value between 0 and 1.In order to extract the pixel data in this situation, the value storedin each byte can be multiplied by 255, and then rounded to an integer.The next operation then depends on the portion of the original byte thatcontains the relevant bits for a desired pixel. If a right bit shift isdesired, the integer can be multiplied by a negative power of two. A“floor” operation can then be used to remove the undesired bits, whichare all to the right of the decimal point after the multiplication. If aleft bit shift is desired, the integer can be multiplied by a positivepower of two, and a “frac” operation can be used to remove the undesiredbits which are located to the left of the decimal point. Multiplying bya negative power of two can then be used to return the remaining bits tothe original position.

Bit Assembly and Data Lookup

Based on the above, a higher density data format can be used to transfer1 bbp format data to a GPU. After identifying the bits corresponding toa pixel, the bits can be assembled to form a single number. For example,in a 6×1 format, the bits can be assembled to form a 10-bit number. A6×5 format could be assembled to form 5 10-digit numbers. Moregenerally, the number of bits corresponding to a pixel can be assembled.Note that a simple arithmetic add operation may be sufficient toassemble the bits, as the bit shifting (or power of two multiplications)describe above can be used so that there is no overlap between the bitsfrom two original 8-bit bytes.

The assembled bits can then be used to determine a pixel value. In anexample using 6×1 oversampled data, the separate red, green, and bluevalues can be calculated for each pixel as it is unpacked in aconventional manner. However, since there are only a relatively smallnumber of possible combinations (1024 for a 10-bit number), applicantshave determined that it can be more efficient to calculate the value forany possible pixel ahead of time. The 10-bit value for a pixel can thenbe used as an index to look up the correct value in a table. Thus avoidsrepeating the same calculation multiple times, thus reducing theprocessing burden on the GPU.

For a data format such as 6×1 data, the total number of bits per pixel(10) results in a manageable number of combinations (1024). However,some oversampling formats result in larger data amounts per pixel, whichcan complicate the determination of a pixel value. For example, anotheravailable oversampling format is 6×5 data, which effectivelyincorporates five columns of 6×1 data. Based on current computationalcapabilities for general purpose computing devices, it is not practicalto pre-calculate the 2⁵⁰ combinations that would be needed to directlyconstruct a lookup table using a 50-bit index. For 6×5 format data, thiscan be addressed by treating the data as five rows of 10-bit data.Lookup tables can be computed for uncorrected pixel values for the10-bit coverage data rows as described above. The five rows of coveragedata can then be vertically filtered to combine the data into a singlepixel value. Optionally, this latter operation can be handled by aconventional pixel shader. Note that based on the above, the term “pixelvalue” can refer to either a complete pixel value or a partial pixelvalue that can be combined with other partial values to form a completevalue. In some situations, a partial pixel value will be referred towhen specifically describing a pixel value that is combined with otherpartial values to form a complete value. An example of a partial pixelvalue can be a value based on one row of 6×5 oversampled coverage data.

Pixel Correction Factor

The above methods can allow for efficient transfer of 1 bpp coveragedata to a GPU, and then efficient calculation of pixel values based onthe coverage data. By itself, this can provide memory and/orcomputational time savings for a GPU. However, additional improvementsare possible if some or all of the pixel correction factors can beincorporated into the lookup table.

For conventional processing of 6×1 coverage data, such as ClearTypedata, the 10 bits of coverage data are assembled and processed toprovide the red, green, and blue pixel information. Based on the valuesof the pixel information, one or more correction values or factors arethen applied to the data. These corrections can be used to improve theappearance of the text formed by the displayed pixels. The correctionscan include (enhanced) contrast adjustment, ClearType level adjustment,and alpha corrections. Additionally, an adjustment may be necessary formonitors that use a blue-green-red format for expressing pixelinformation, as opposed to a red-green-blue format. Conventionally, eachof these correction factors is applied to each pixel based on the red,green, and blue channel values in the data, and requires separateadditional calculations after determining the uncorrected pixel value.

In some embodiments, one or more of the correction factors applied topixel values can be pre-calculated and incorporated into the lookuptable. Many of the corrections applied to pixel values are fullyspecified by the assembled coverage data bits. For example, theassembled 10-bit number for 6×1 format coverage data provides sufficientinformation to determine various corrections that can be applied to thepixel value. Such corrections can include an enhanced contrastcorrection, a ClearType level adjustment, or an alpha value correction.Since the corrections to the pixel value can also be determined ahead oftime, these corrections can also be pre-calculated. This allows thelookup table to store a corrected pixel value, which further reduces thenumber of calculations required by the GPU.

It is noted that one or more of the correction factors applied to pixelsused for text rendering may be variable based on a user or hardwaresetting. For example, the correction factors applied to a pixel valuemay be dependent on the background and text colors selected by a user ora contrast setting of a hardware display device. As a result, ifcorrections to pixel values are included in the lookup table, a newlookup table will be needed each time a change is made that modifies thecorrection factors. One way to accommodate this can be to have an atlasof lookup tables. For common user and display settings and/or recentcombinations of settings, a lookup table can be stored in an atlas oflookup tables. If a new combination of settings is selected that has notbeen computed before, a new table can be calculated and added to theatlas. In order to conserve memory, the atlas of lookup tables caninclude a limited number of tables. For example, 20 tables for 10-bitdata lookup can be stored in less than 96 kB of space. When a new tableis added, one of the tables can be selected for removal, such as theleast recently used table.

The data corrections for a pixel value can present an additionalchallenge for large data formats. For example, data in a 6×5 formatrequires a total of 50 bits to specify a pixel value. As describedabove, a lookup table for uncorrected pixel values can be generated byanalyzing the data as five 10-bit data rows. However, at least some ofthe correction factors for pixel value are based all of the oversamplingdata for a pixel, and cannot be readily separated out for inclusion in10-bit data table corresponding to a portion of the oversampling data.For example, an enhanced contrast correction for 6×5 pixel values shouldbe calculated and applied after the 10-bit data rows are verticallyintegrated. For the pixel corrections on larger data formats, one optioncan be to calculate the corrections in the conventional way based on thedata retrieved from the lookup table. Alternatively, in an examplerelated to 6×5 format coverage data, the result of the verticalintegration is three grayscale channels corresponding to the red, green,and blue channels of a display monitor. For each of these grayscalechannels separately, at least some of the correction data can be storedin an appropriately sized table. Thus, some calculations can be avoidedby having lookup tables for some correction values, while conventionallycalculating the remaining corrections.

FIG. 6 schematically shows a process flow for display of text pixelsaccording to an embodiment of the invention. In FIG. 6, an expanded viewof the process is provided to provide overall context. Texture coveragerectangle and texture coordinates 610 represent the grid that is usedfor rasterizing text. Vertex shader 620 includes functionality forperforming a screen space transform 622 and copying texture coordinates624. Pixel shader 630 includes functionality for performing a coveragecalculation 632 and calculating a correction, such as an alphaadjustment 634. The lbpp coverage data 660 is processed by pixel shader630. As part of this processing, some calculations can be replaced bycoverage lookup table 672 and alpha lookup table 674. Blend stage 640includes functionality for performing additional blending, such asClearType blending 642.

Having briefly described an overview of various embodiments of theinvention, an exemplary operating environment suitable for performingthe invention is now described. Referring to the drawings in general,and initially to FIG. 1 in particular, an exemplary operatingenvironment for implementing embodiments of the present invention isshown and designated generally as computing device 100. Computing device100 is but one example of a suitable computing environment and is notintended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should the computing device 100be interpreted as having any dependency or requirement relating to anyone or combination of components illustrated.

Embodiments of the invention may be described in the general context ofcomputer code or machine-useable instructions, includingcomputer-executable instructions such as program modules, being executedby a computer or other machine, such as a personal data assistant orother handheld device. Generally, program modules, including routines,programs, objects, components, data structures, etc., refer to code thatperform particular tasks or implement particular abstract data types.The invention may be practiced in a variety of system configurations,including hand-held devices, consumer electronics, general-purposecomputers, more specialty computing devices, and the like. The inventionmay also be practiced in distributed computing environments where tasksare performed by remote-processing devices that are linked through acommunications network.

With continued reference to FIG. 1, computing device 100 includes a bus110 that directly or indirectly couples the following devices: memory112, one or more processors 114, one or more presentation components116, input/output (I/O) ports 118, I/O components 120, and anillustrative power supply 122. Bus 110 represents what may be one ormore busses (such as an address bus, data bus, or combination thereof).Although the various blocks of FIG. 1 are shown with lines for the sakeof clarity, in reality, delineating various components is not so clear,and metaphorically, the lines would more accurately be grey and fuzzy.For example, one may consider a presentation component such as a displaydevice to be an I/O component. Additionally, many processors havememory. The inventors hereof recognize that such is the nature of theart, and reiterate that the diagram of FIG. 1 is merely illustrative ofan exemplary computing device that can be used in connection with one ormore embodiments of the present invention. Distinction is not madebetween such categories as “workstation,” “server,” “laptop,” “hand-helddevice,” etc., as all are contemplated within the scope of FIG. 1 andreference to “computing device.”

The computing device 100 typically includes a variety ofcomputer-readable media. Computer-readable media can be any availablemedia that can be accessed by computing device 100 and includes bothvolatile and nonvolatile media, removable and non-removable media. Byway of example, and not limitation, computer-readable media may comprisecomputer storage media and communication media. Computer storage mediaincludes volatile and nonvolatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer-readable instructions, data structures, program modules orother data. Computer storage media includes, but is not limited to,Random Access Memory (RAM), Read Only Memory (ROM), ElectronicallyErasable Programmable Read Only Memory (EEPROM), flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otherholographic memory, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, carrier wave, or any othermedium that can be used to encode desired information and which can beaccessed by the computing device 100. In an embodiment the computerstorage media can be tangible computer storage media. In an embodimentthe computer storage media can be non-transitory computer storage media.

The memory 112 includes computer-storage media in the form of volatileand/or nonvolatile memory. The memory may be removable, non-removable,or a combination thereof. Exemplary hardware devices include solid-statememory, hard drives, optical-disc drives, etc. The computing device 100includes one or more processors that read data from various entitiessuch as the memory 112 or the I/O components 120. The presentationcomponent(s) 116 present data indications to a user or other device.Exemplary presentation components include a display device, speaker,printing component, vibrating component, and the like.

The I/O ports 118 allow the computing device 100 to be logically coupledto other devices including the I/O components 120, some of which may bebuilt in. Illustrative components include a microphone, joystick, gamepad, satellite dish, scanner, printer, wireless device, etc.

FIG. 2 details components of the computing device 100 that may be usedfor processing a glyph and rendering text. Some of the GPU 124 hardwareincludes one or more procedural shaders. Procedural shaders arespecialized processing subunits of the GPU 124 for performingspecialized operations on graphics data. An example of a proceduralshader is a vertex shader 126, which generally operates on vertices. Forinstance, the vertex shader 126 can apply computations of positions,colors and texturing coordinates to individual vertices. The vertexshader 126 may perform either fixed or programmable functioncomputations on streams of vertices specified in the memory of thegraphics pipeline. Another example of a procedural shader is a pixelshader 128. For instance, the outputs of the vertex shader 126 can bepassed to the pixel shader 128, which in turn operates on eachindividual pixel. After a procedural shader concludes its operations,the information is placed in a GPU buffer 130, which may be presented onan attached display device or may be sent back to the host for furtheroperation.

The GPU buffer 130 provides a storage location on the GPU 124 as astaging surface or scratch surface for glyph textures. As variousrendering operations are performed with respect to a glyph texture, theglyph may be accessed from the GPU buffer 130, altered and re-stored onthe buffer 130. As known to those skilled in the art, the GPU buffer 130allows the glyph being processed to remain on the GPU 124 while it istransformed by a text pipeline. As it is time-consuming to transfer aglyph from the GPU 124 to the memory 112, it may be preferable for aglyph texture or bitmap to remain on the GPU buffer 130.

With respect to the pixel shader 128, specialized pixel shadingfunctionality can be achieved by downloading instructions to the pixelshader 128. For instance, downloaded instructions may enable specializedmerging, filtering, or averaging of the glyph texture. Furthermore, thefunctionality of many different operations may be provided byinstruction sets tailored to the pixel shader 128. The ability toprogram the pixel shader 128 is advantageous for text renderingoperations, and specialized sets of instructions may add value by easingdevelopment and improving performance. By executing these instructions,a variety of functions can be performed by the pixel shader 128,assuming the instruction count limit and other hardware limitations ofthe pixel shader 128 are not exceeded.

FIG. 3 depicts a flow chart showing a method according to an embodimentof the invention. In the embodiment shown in FIG. 3, 1-bit-per-pixelcoverage data is received 310. The coverage data has an oversampledformat, such as a 6×1 format. The received coverage data is stored in astorage format of greater than 1 bit per byte of storage. Bits ofcoverage data are assembled 320 to form an n-bit value. The n-bit valuecorresponds to a pixel having the oversampled format, such as a 10-bitvalue for a 6×1 format. A pixel value table is indexed 330 using then-bit value. At least one pixel value corresponding to the indexedlocation is retrieved 340. A pixel is then rendered 350 based on theretrieved at least one pixel value.

FIG. 4 depicts a flow chart showing another method according to anembodiment of the invention. In the embodiment shown in FIG. 4,1-bit-per-pixel coverage data is received 410. The coverage data has anoversampled format, such as a 6×5 format. The received coverage data isstored in a storage format of greater than 1 bit per byte of storage.Bits of coverage data are assembled 420 to form a plurality of n-bitvalues. Each of the n-bit values corresponds to a portion of a pixelhaving the oversampled format, such as a group of 10-bit values that arepart of pixel coverage data for a 6×5 format. Each of the n-bit valuesalso includes bits from a plurality of bytes. A pixel value table isindexed 430 a plurality of times using the plurality of n-bit values.The same pixel value table can be indexed a plurality of times, oroptionally the n-bit values can be used to index more than one pixelvalue table. A plurality of partial pixel values corresponding to theindexed locations are retrieved 440. The retrieved partial pixel valuesare combined 450 to form a plurality of combined pixel values. A pixelis then rendered 460 based on the combined pixel values.

FIG. 5 depicts a flow chart showing a method according to yet anotherembodiment of the invention. In the embodiment shown in FIG. 5,1-bit-per-pixel coverage data is received 510. The coverage data has anoversampled format, such as a 6×5 format. The received coverage data isstored in a storage format of greater than 1 bit per byte of storage. Abyte of stored pixel coverage data is sampled 520 as a floating pointdata type. The byte includes one or more bits corresponding to coveragedata for a pixel to be rendered. The sampled floating point byte istransformed 530 to segregate the one or more bits in the stored data.For example, the transformation can be a multiplication by a power oftwo, so that the bits of interest are segregated on one side of thedecimal point for the number. The transformed byte is truncated 540 toremove bits not corresponding to the one or more segregated bits. Thesegregated bits are assembled 550 with at least one other portion ofsegregated bits to form an n-bit value corresponding to a pixel havingthe oversampled format. A pixel value table is indexed 560 using then-bit value. At least one pixel value is retrieved 570 corresponding tothe indexed location. A pixel is then rendered 580 based on theretrieved at least one pixel value.

EXAMPLE

The following is a prophetic example. A change to a display setting isdetected for a physical display that is depicting antialiased objects,such as text. The pixels on the physical display are being renderedbased on 6×1 oversampled 1 bpp coverage data. The change can be a changein a setting on the physical display device, a change in the color oftext to be displayed, or another change. Based on the change, thesettings that impact display pixels are detected. The detected settingsare compared with the settings for lookup tables stored in an atlas oflookup tables. If a matching group of settings is not found, a newlookup table is created. The lookup table provides the corrected pixelvalue for each of the possible 2¹⁰ combinations possible for 6×1coverage data. The corrected pixel value includes the corrections forthe pixel value, such as alpha correction, ClearType correction, or anyother type of correction. The new lookup table is added to the atlas,and the oldest lookup table in the atlas is removed.

The new lookup table is then used to render objects on the displaydevice, such as text glyphs. The glyphs for display are represented as6×1 oversampled 1 bpp coverage data. The 1 bpp data is packed by placing8 bits of data into a byte for transfer from a CPU to a GPU. Aftertransfer to the GPU, the data for each pixel is extracted by accessingthe two bytes containing data corresponding to the pixel. Bit shiftingoperations are used to isolate the bits of interest, and a 10-bit numberis formed from the bits of interest. This 10-bit number is then used toindex the new lookup table. The stored pixel value corresponding to the10-bit number is retrieved and used for display. If all corrections areincorporated into the stored value, the stored pixel value may not needany other correction calculations.

Additional Embodiments

In a first embodiment, a method for antialiased rendering is provided.The method includes: receiving 1-bit-per-pixel coverage data having anoversampled format, the received coverage data having a storage formatof greater than 1 bit per byte of storage; assembling bits of coveragedata to form an n-bit value corresponding to a pixel having theoversampled format; indexing a pixel value table using the n-bit value;retrieving at least one pixel value corresponding to the indexedlocation; and rendering a pixel based on the retrieved at least onepixel value.

In a second embodiment, a method according to the first embodiment isprovided, wherein assembling bits of coverage data to form an n-bitvalue includes: sampling a byte of stored pixel coverage data as afloating point data type, the byte including one or more bitscorresponding to coverage data for a pixel to be rendered; transformingthe sampled floating point byte to segregate the one or more bits in thestored data; truncating the transformed byte to remove bits notcorresponding to the one or more segregated bits; and assembling thesegregated bits with at least one other portion of segregated bits toform an n-bit value corresponding to a pixel having the oversampledformat.

In a third embodiment, a method according to any of the aboveembodiments is provided, wherein the oversampled format for the coveragedata is a 6×1 format, the n-bit value corresponding to a 10-bit value.

In a fourth embodiment, a method according to any of the aboveembodiments is provided, further comprising combining the at least onepixel value with at least a second pixel value to form a combined pixelvalue, wherein the rendered pixel is based on the combined pixel value.

In a fifth embodiment, a method according to any of the aboveembodiments is provided, wherein assembling bits to form a plurality ofn-bit values comprises assembling bits from a plurality of bytes.

In a sixth embodiment, a method for antialiased rendering is provided.The method includes receiving 1-bit-per-pixel coverage data having anoversampled format, the received coverage data having a storage formatof greater than 1 bit per byte of storage; assembling bits of coveragedata to form a plurality of n-bit values, each n-bit value correspondingto a pixel having the oversampled format and each n-bit value includingbits from a plurality of bytes; indexing a pixel value table a pluralityof times using the plurality of n-bit values; retrieving a plurality ofpixel values corresponding to each indexed location; combining retrievedpixel values corresponding to a plurality of indexed locations to form aplurality of combined pixel values; and rendering a pixel based on theplurality of combined pixel values.

In a seventh embodiment, a method according to the sixth embodiment isprovided, wherein retrieving a plurality of pixel values comprisesretrieving three channels of pixel values.

In an eighth embodiment, a method according to the seventh embodiment isprovided, wherein combining the retrieved pixel values comprisescombining the three channels of pixel values to form three combinedchannel pixel values.

In a ninth embodiment, a method according to the eighth embodiment isprovided, further comprising: indexing a correction factor table using acombined channel value to retrieve a correction factor; and applying thecorrection factor to the combined channel value.

In a tenth embodiment, a method according to any of the sixth throughninth embodiments is provided, wherein the oversampled format for thecoverage data is a 6×5 format, wherein each n-bit value corresponds to a10-bit value.

In an eleventh embodiment, a method according to any of the aboveembodiments is provided, wherein the received coverage data has astorage format of at least 8-bits-per-byte.

In a twelfth embodiment, a method according to any of the aboveembodiments is provided, wherein the 1-bit-per-pixel coverage datarepresents coverage data for a text glyph.

In a thirteenth embodiment, a method according to any of the aboveembodiments is provided, further comprising: detecting a change thatmodifies a pixel correction factor; and constructing a table of pixelvalues that incorporates the modified pixel correction factor, whereinindexing a pixel value table using the n-bit value comprises indexingthe constructed table.

In a fourteenth embodiment, a method according to the thirteenthembodiment is provided, wherein the constructed table is stored in anatlas of tables.

Embodiments of the present invention have been described in relation toparticular embodiments, which are intended in all respects to beillustrative rather than restrictive. Alternative embodiments willbecome apparent to those of ordinary skill in the art to which thepresent invention pertains without departing from its scope.

From the foregoing, it will be seen that this invention is one welladapted to attain all the ends and objects hereinabove set forthtogether with other advantages which are obvious and which are inherentto the structure.

It will be understood that certain features and subcombinations are ofutility and may be employed without reference to other features andsubcombinations. This is contemplated by and is within the scope of theclaims.

What is claimed is:
 1. A system for performing antialiased rendering,comprising: a processor, an associated display, and an associated memorycontaining computer-executable instructions, the processor executing thecomputer-executable instructions contained in the associated memory toprovide a system configured to: receive 1-bit-per-pixel coverage datahaving an oversampled format, the received coverage data having astorage format of greater than 1 bit per byte of storage; sample a byteof stored pixel coverage data as a floating point data type, the byteincluding one or more bits corresponding to coverage data for a pixel tobe rendered; transform the sampled floating point byte to segregate theone or more bits in the stored data; truncate the transformed byte toremove bits not corresponding to the one or more segregated bits;assemble the segregated bits of coverage data with at least one otherportion of segregated bits to form an n-bit value corresponding to apixel having the oversampled format, the assembling comprising;multiplying the truncated, transformed byte by a power of two to modifythe location of the segregated bits in the truncated, transformed byte;and adding the multiplied, truncated, transformed byte to a second bytecontaining segregated bits, the segregated bits occupying different bitlocations in the multiplied, truncated, transformed byte and the secondbyte; index a pixel value table using the n-bit value; retrieve, fromthe pixel value table, at least one pixel value stored in the pixelvalue table, the retrieved at least one pixel value corresponding to theindexed location, the retrieved at least one pixel value comprisingcolor information; and render a pixel on the associated display based onthe retrieved at least one pixel value.
 2. The system of claim 1,wherein the n-bit value corresponds to a 10-bit value in the oversampledformat.
 3. The system of claim 1, wherein the received coverage data hasa storage format of at least 8-bits-per-byte.
 4. The system of claim 1,wherein the 1-bit-per-pixel coverage data represents coverage data for atext glyph.
 5. The system of claim 1, the system being furtherconfigured to: detect a change that modifies a pixel correction factor;and construct a table of pixel values that incorporates the modifiedpixel correction factor, wherein indexing a pixel value table using then-bit value comprises indexing the constructed table.
 6. The system ofclaim 5, wherein the constructed table is stored in an atlas of tables.7. The system of claim 1, wherein assembling bits to form a plurality ofn-bit values comprises assembling bits from a plurality of bytes.
 8. Amethod for antialiased rendering, comprising: receiving 1-bit-per-pixelcoverage data having an oversampled format, the received coverage datahaving a storage format of greater than 1 bit per byte of storage;sampling bytes of stored pixel coverage data as a floating point datatype, the bytes each including one or more bits corresponding tocoverage data for pixels to be rendered; transforming the sampledfloating point bytes to segregate the one or more bits in the storeddata; truncating the transformed bytes to remove bits not correspondingto the one or more segregated bits; assembling the segregated bits ofcoverage data to form a plurality of n-bit values, each n-bit valuecorresponding to a pixel having the oversampled format and each n-bitvalue including bits from a plurality of bytes, assembling comprising;multiplying each truncated, transformed byte by a power of two to modifythe location of the segregated bits in the truncated, transformed bytes;and adding the multiplied, truncated, transformed bytes to a second bytecontaining segregated bits, the segregated bits occupying different bitlocations in the multiplied, truncated, transformed byte and the secondbyte; indexing a pixel value table a plurality of times using theplurality of n-bit values; retrieving, from the pixel value table, aplurality of pixel values stored in the pixel value table, the retrievedplurality of pixel values corresponding to each indexed location, theretrieved plurality of pixel values comprising color information;combining retrieved pixel values corresponding to a plurality of indexedlocations to form a plurality of combined pixel values; and rendering apixel based on the plurality of combined pixel values.
 9. The method ofclaim 8, wherein retrieving a plurality pixel values comprisesretrieving three channels of pixel values.
 10. The method of claim 9,wherein combining the retrieved pixel values comprises combining thethree channels of pixel values to form three combined channel pixelvalues.
 11. The method of claim 10, further comprising: indexing acorrection factor table using a combined channel value to retrieve acorrection factor; and applying the correction factor to the combinedchannel value.
 12. The method of claim 8, wherein each n-bit valuecorresponds to a 10-bit value.
 13. The method of claim 8, wherein thereceived coverage data has a storage format of at least 8-bits-per-byte.14. The method of claim 8, wherein the 1-bit-per-pixel coverage datarepresents coverage data for a text glyph.
 15. The method of claim 8,wherein assembling bits to form a plurality of n-bit values comprisesassembling bits from a plurality of bytes.
 16. A method for renderingtext, comprising: receiving 1-bit-per-pixel coverage data having anoversampled format, the received coverage data having a storage formatof greater than 1 bit per byte of storage; sampling a byte of storedpixel coverage data as a floating point data type, the byte includingone or more bits corresponding to coverage data for a pixel to berendered; transforming the sampled floating point byte to segregate theone or more bits in the stored data; truncating the transformed byte toremove bits not corresponding to the one or more segregated bits;assembling the segregated bits with at least one other portion ofsegregated bits to form an n-bit value corresponding to a pixel havingthe oversampled format, the assembling comprising: multiplying thetruncated, transformed byte by a power of two to modify the location ofthe segregated bits in the truncated, transformed byte; and adding themultiplied, truncated, transformed byte to a second byte containingsegregated bits, the segregated bits occupying different bit locationsin the multiplied, truncated, transformed byte and the second byte;indexing a pixel value table using the n-bit value; retrieving at leastone pixel value corresponding to the indexed location; and rendering apixel based on the retrieved at least one pixel value.
 17. The method ofclaim 16, wherein transforming the sampled floating point byte comprisesmultiplying the value in the byte by a power of two to segregate the oneor more bits corresponding to a pixel to be rendered relative to adecimal point.
 18. The method of claim 16, wherein the the n-bit valuecorresponds to a 10-bit value in the oversampled format.
 19. The methodof claim 16, further comprising combining the at least one pixel valuewith at least a second pixel value to form a combined pixel value,wherein the rendered pixel is based on the combined pixel value.
 20. Themethod of claim 16, wherein the 1-bit-per-pixel coverage data representscoverage data for a text glyph.